Mechanisms, models and tools for flexible protocol development and accurate network experimentation

ion into micro protocols reduces the complexity of a protocol. It inherently provides structuring and enables understanding, easing network experimentation and engineering. Furthermore, encapsulation enables a dynamic instantiation of 100 4. Protocol Factory components, resulting in adaptive protocol stacks. This allows ProFab to create and exchange component instances dynamically at runtime based on changing protocol needs. Basing on the component model of micro protocols, we provide a software architecture to realize modules. Additionally, we describe their composition to protocol stacks and introduce a run-time environment for their dynamic adaptation. The software architecture consists of three main building blocks: • Implementation of Modules: Modules encapsulate protocol mechanisms such as congestion control, packet forwarding or integrity protection. Hence, the software architecture must provide a programming paradigm and language for their implementation. • Composition to Protocol Stacks: Apart from realization of individual modules we require mechanisms to describe the composition of modules to protocol stacks, so called compounds. Hence, we need language support to instantiate and configure modules to requirements of individual protocols. Additionally, we need to define mechanisms for module interaction, i.e., the semantics of gates, and their connection to a component graph that assembles a protocol stack. • Run-Time Environment: To realize connections, flows and adaptive protocol stacks, we require a run-time environment that supports the dynamic instantiation and recomposition of modules. For example, to realize a TCP connection we need to create module instances and integrate these dynamically into the protocol stack. Additionally, these dynamics enable customized protocol stacks and adaption of compositions to changing application requirements. 4.2.1.2 Requirements Apart from the description of modules and their composition to protocol stacks, the software architecture and its programming language and paradigms need to meet the following requirements: (1) portability, (2) resource efficiency, and (3) optimization of generic modules and their compositions. • Portability: Apart from reusability of micro-protocols and their modules across protocols and protocol layers, one key goal of ProFab is their reuse across platforms. Hence, the language to describe modules and their composition needs to be supported natively on all target platforms, including operating system kernels and devices with tightly constrained resources such as sensor nodes. • Optimization: To enable their reuse, micro protocols are realized protocol independent. Hence, configurations adapt micro protocols to the requirements of individual protocols. For example, the forwarding module provides a longestprefix-match algorithm and the configuration of IPv4 tailors this algorithm to match 32bit addresses. Hence, we require a compiler infrastructure that configures and composes modules at low overhead, i.e., it reduces the performance penalty of modularization and generic code. 4.2. Software Architecture for Micro Protocols 101 • Resource Efficiency: To enable a deployment in operating system kernels and on resource constrained devices, the programming language needs to designed for resource efficiency. This includes performance of data processing and memory consumption. 4.2.1.3 Target Protocols and Scenarios The discussion of micro protocols in Chapter 3 focuses on the network and transport layers. However, our goal is to design ProFab’s software architecture so that it is not limited to these protocol layers. For example, our analysis indicates, that application level protocols also share a large degree of similarities (see Section 3.6.1.1). Hence, the software architecture it is intented to enable communication protocol development and experimentation ranging from the network layer to the application layer, including overlays, peer-to-peer systems and sensor networks. Especially, it aims to ease the development and evaluation of new distributed systems and protocols. 4.2.1.4 Restrictions The mechanisms and tools presented in this work ease prototyping and evolution of communication protocols. Our main focus lies on protocol experimentation, explicitly trading composable micro protocols for strongly interleaved and optimized protocols. Furthermore, we do not aim to change the way how protocols are implemented in the OS kernel or even propose this library of micro protocols as such. We are well aware that vendors rely on their own implementations ensuring an optimization of a protocol to its dedicated use-case, the targeted platform, and application. Similarly, this ensures reliability due to independent implementations and reduces the dependency of vendors from third-party tools. This work focuses on micro protocols in the higher protocol layers, e.g., from the network layer to the application layer. Although the link layer shares similarities with these layers, we exclude it from this work. The main reason for this is, that link layer protocols are typically not implemented on general purpose processors (GPU). Instead, they are implemented on custom chips, FPGAs, ASICs and DSPs, all requiring specialized programming languages and paradigms. 4.2.2 Analysis of Design Choices In the discussion of our design goals we derived features and requirements of the software architecture. As the first step, we identify a programming language that provides the fundament to meet the requirements discussed. Today’s typical programming languages fall into three categories: (1) Compiled languages such as C or C++, (2) virtual machine based ones such as Java, and (3) scripted languages such as Python (see Table 4.1). While the powerful object model and their ease of use make modern languages such as Java and Python interesting choices for our software architecture, both have a key limitation: Their resource consumption in terms of performance overhead and memory is too high for our target 102 4. Protocol Factory Feature / Language Compiled VM-Based Script C C++ Java Python Modularity Functions Objects Objects Objects Resource Requirements Low Medium High High Availability High Restricted Low Low Gates Functions Interfaces Interfaces Interfaces Delegates Optimization Macros Templates Virtual Machine None JIT Table 4.1 Different programming languages as design choices in ProFab. systems. As a result, they are not available for resource constrained environments such as OS kernels and wireless sensor nodes. Hence, regarding the availability of compilers and supported platforms, our language choices are between C and C++. In the following we discuss their features in detail. 4.2.2.1 Choice I: C++ Based on this analysis, C++ appears as an intuitive choice. It is widely supported and features object orientation, including the dynamic creation of class instances. The template concept in C++ is a powerful tool to optimize protocol independent modules to a specific use case at compilation time. Additionally, its programming model allows for pointers and casts, providing sufficient low level capabilities for protocol implementations. Moreover, relying on C++ would allow us to utilize the software architecture of related approaches such as Click. However, the support for C++ in operating system kernels and on sensor node platforms is limited. For example, Linux kernel developers highly discourage the use of C++ in the kernel due to efficiency and stability problems [T04] for the following reasons: First, the Linux kernel does not provide the required C++ run-time. Second, the Linux kernel is not written according to C++ namespace rules and keywords. As a result, the Linux kernel requires patching to allow the integration of C++ modules. And third, the stack size of the Linux kernel is too small to handle exceptions. Similarly, Microsoft discourages the use of C++ for network protocols in all Windows kernels. Moreover, C++ features such as exceptions are not supported in these prioritized contexts and on many embedded systems. To enable the use of C++ in the Linux kernel, the developers of Click patch the kernel, provide a small run-time environment, their own C++ libraries, and restrict their use of exceptions. On embedded systems we see similar challenges. For example, the avg-gcc compiler required for the AtMega128L micro-controller [Atm] on the widespread Mica2, MicaZ and Mica2Dot sensor nodes [Cro]currently supports neither constructors, destructors, exceptions nor C++ libraries [Tea]. The msp-gcc compiler for the Texas Instruments msp430 micro-controller [Tex] on the sensor nodes of the telos family[PSC05] has similar limitations [DL]. Overall, the reasons for this lack of availability is manifold: For example, object management in C++ hides memory allocations from the user, a problem in operation system kernels where memory allocations must be executed differently depending 4.2. Software Architecture for Micro Protocols 103 module Name{ GateTypeA@in in1; GateTypeB@in in2; GateTypeA@out out1; GateTypeB@out out2;